Many positive consequences have resulted from the continual improvements in the price performance of microcomputer technologies. For example, graphical user interface driven applications have displaced less user-friendly command driven applications. Also, microcomputers have proliferated from the desktop computer to the laptop computer, personal digital assistants, cellular telephones, set-top boxes for televisions, and myriad other devices.
On the other hand, the improvements in microcomputer technologies have also resulted in some issues. With improvements in microprocessor systems, data transfer to and from the microprocessor presents more of a concern in processing throughput. Similarly, with the proliferation of microcomputer devices, demand on both wired and wireless networking bandwidth is constantly increasing. At the same time, the luxury of fast microprocessors and inexpensive large capacity memory systems has led to software engineers and programmers tending to generate less efficient code. The cost of the human capital to develop efficient code cannot be justified in the face of cheaper processing power that in many cases allows relatively inefficient code to run sufficiently quickly.
Within this context, there are challenges faced in creating an interactive computer application in today's environment. First, there is a conflict between the proliferation of computing devices on one hand and the tendency to create less efficient code because of the improved price performance of hardware. To take one example, a ubiquitous yet often overlooked home computer is the digital set-top box (STB) present in households receiving digital cable or digital satellite television signals. Most applications evident to the user are simple, such as changing channels; displaying a program guide; identifying the program; name; specifying the start time and run time of a program; and perhaps a short synopsis of the program. At the same time, the STB has to undertake many functions which may not be apparent to the user. For example, the STB has to coordinate which “channel” chosen by the user is represented by which data stream, and has to receive and decode the mass of video and audio data blocks which contain the program content.
Improved price performance of hardware has made the proliferation of these devices affordable and, therefore, practical. However, the computer hardware within the STB is very rudimentary by today's standards. A typical STB is operated by a relatively slow microprocessor, has very little random access memory, and little or no program storage. Because of this last reason, the STB frequently has to update the application code or data it stores, and cannot store large quantities of data at any time. Further, even though the STB necessarily has access to broadband data input, even if more memory were available to the STB, loading large quantities of non-video and non-audio data is not readily possible because the data stream is largely filled by video and audio data blocks for all the channels made available to the user through the cable or satellite feed.
Overcoming such concerns would allow STBs to be more fully exploited and thereby enhance the television production and viewing experience. For example, the addition of graphical information in a television program conventionally is performed in show postproduction by an editor, and the information actually becomes embedded as part of the visual data transmitted by the program. This same information could be received as data and superimposed on the video images of the telecast. Moreover, STBs could be used to allow user interaction with a program, such as by playing along with game shows or purchasing items displayed during a telecast. Currently, while it is possible to offer a telephone number, a web address, a vendor name, and similar information to allow an interested viewer to purchase an item indirectly, there are not opportunities to interactively purchase via the STB.
Second, when creating an application to be interactively engaged by a user, the designer of the application considers the application's behaviors in response to the user's actions as well as other changing circumstances. These circumstances may include the passage of time, direct user interaction with the input interface of the computer, or alterations in internal or external control signals. The challenge of creating a computer application to encapsulate the desired behavior is to accurately define these behaviors, then incorporate the behavior into a series of algorithmic statements. Typically, a designer or implementer of an interactive application will create explicit algorithmic statements in the coding language which implement the desired behavior. Control statement constructs, such as IF-THEN-ELSE or DO-WHILE logical constructions, are used to test for various conditions, the result of which can initiate simple operations. The sequential testing of these multiple control statements and the combination of the simple operations keyed thereby can then be combined into more complex behavior to create the appearance of a sophisticated application.
These first and second challenges may, however, conflict with each other. Capturing desired application behavior in a series of testing statements can require extensive code. Further, in the STB environment, both storing and securing the bandwidth to obtain necessary conditional coding sections present problems.
In order to try to effectuate desired conditional programming behavior in a compact data size, some program logic can be converted into equivalent data content. The data content, with the desired behavioral aspects of the application embedded therein, can interact with the control logic to execute the desired behavior without downloading all new application code for each desired set of functions.
One example of how this is done is a data-driven control mechanism such as that described by Watanabe et al. in U.S. Pat. No. 6,223,347, “DATA DISPLAY CONTROL APPARATUS” (“Watanabe”). Watanabe discloses a system which uses pre-encoded data to specify changing the appearance of an application according to predetermined behaviors which are instituted by the receipt of user actions, or by the passage of time. For each of a set of display screens, modifications of properties of elements of the screen can be made by invoking a “handler.” A handler is a small byte code sequence which accomplishes some change in the system properties, such as making a button visible or invisible, or displaying an alternative screen. FIG. 1, which represents FIG. 6 from Watanabe, shows a pre-encoded data element 100 as disclosed by Watanabe for controlling the appearance of a single display screen.
Viewed practically, Watanabe's data element 100 is a code fragment which dictates the response of the application in response to changing conditions. The data element 100 manifests an IF-THEN construct keyed by whether a user selects a VIDEO button 106 or a STEREO button 110. Moreover, the data element only encapsulates one aspect of the behavior for one single, conditional choice. To create a complex behavioral response to the user input, a series of stacked data elements like data element 100 would have to be created.
In addition, the system of Watanabe has a drawback which is shared by other similar systems such as web browsers. The Watanabe solution employs discrete code fragments which are executed in response to particular behavior, in just the same way that a web page is encoded to activate a link when the user clicks on a button or block to which the link is associated. As such, just as in a web browser the navigation available to the user is limited to the pre-defined URL links embedded in the source code for the page, under Watanabe the programming logic is fixed at design time to handlers pre-coded in the application. Also like a web browser, in which the transition to a new page represented by the link is automatic in response to the link being chosen, under Watanabe's system the behavior is responsive to the last conditional branch taken by the system in response to a user selection. Watanabe cannot take account of previous states from which the user selection was made or based on a combination of variables. The user's experience is based solely on the application's response to the last individual selection made by the user.
One alternative to the simple selection/pre-encoded direct response system of Watanabe is to create an executable application which implements behavior based on conditional testing of multiple application variables or inputs. However, an inefficiency inherent in constructing application behavior from conditional program logic is that each potential alternative condition must continually be tested for and operated upon. Some reuse of code is always possible, but generally the code has to be modified to manifest all the variables and the consequences of their values to handle each new special case of behavior. In other words, with reference to the example from Watanabe, the same byte code specified in the Bytecode_Part 150 would have to be incorporated into the conditional program logic, but would be surrounded by code to test for which subset of byte code should be executed. This conditional code must be executed before the ‘operational’ effect can be realized from the core byte code, which leads to inefficiency.
Adding or updating code also presents concerns from the standpoint of program storage, loading time, and data communications bandwidth. FIG. 2A shows a computer system 200 and a typical application 202 residing within the system 200. The system 200 presents a hardware layer 204 which is controlled by a low-level hardware operating system 206, such as the Basic Input/Output System (BIOS) residing on a typical personal computer. An operating system or middleware 208 typically runs above the hardware operating system 206. Ultimately, the application 202 then resides on top of the operating system. If the application 202 has to be swapped out, updated, or otherwise changed, entire modules of code, or perhaps the entire application are changed. As shown in FIG. 2B, loading a new, different, revised, or updated application 202 would consume appreciable bandwidth of a data path 250. Moreover, if the pathway is a relatively slow network line rather than a relatively fast local bus, the time and bandwidth required to communicate the application would be appreciable for one such transmission. The aggregate bandwidth consumed for a number of changes or updates can becomes a tremendous bandwidth concern.
Thus, there is an unmet need in the art for controlling appearance and execution of computer applications without having to create, load, and store code instruction segments to control desired computer behavior in response to changing variables and conditions in which the application operates.